home *** CD-ROM | disk | FTP | other *** search
/ Atari Mega Archive 1 / Atari Mega Archive - Volume 1.iso / lists / mint / l_1599 / 1370 < prev    next >
Encoding:
Internet Message Format  |  1994-08-27  |  1.7 KB
  1. Date: Mon, 9 May 94 02:14 CDT
  2. From: ekl@sdf.lonestar.org (Evan K. Langlois)
  3. To: mint@atari.archive.umich.edu
  4. Subject: UniFS
  5.  
  6.  
  7. Here's a weird idea.   How about combining ramfs with Unifs?  That way the
  8. Unified file system could store files like a real filesystem?
  9.  
  10. Or perhaps add a command to MiNT.CNF that would allow writes to U: to be
  11. redirected to some other path?  So that it would show up in U:\ but get stored
  12. elsewhere?
  13.  
  14. If the DIRSEP #define is changed to an OR conditional, like :
  15. #define DIRSEP(p)  (((p) == '\\') || ((p) == '/'))
  16.  
  17. then, what else would be required to use a Unix path separator in system
  18. calls?
  19.  
  20. Would cach'ing fs->lookup provide much of a speed advantage?  Some people
  21. were talking about putting a "cookie cache" into MiNT and it wouldn't be
  22. very hard (assuming that you don't have to release a cookie back to the 
  23. filesystem immediately, and you can let the cache keep it for awhile without
  24. hurting something) then it should be pretty straightforward.  Say, an array
  25. of 32 cookies to cache?   I've already worked out a way to do it and I'll
  26. hack it in this weekend and see if it makes much of a difference, but I
  27. don't think there will be much improvement.
  28.  
  29. Oh .. I think TOSWIN has a really BAD memory leak.  For some reason, when I
  30. do a PS or a TOP, MiNT increasing has more and more memory, until it gets 
  31. over 2 MB and I have to reboot.  I first thought it was tfork, but I used
  32. that directly from a shell quite a bit and there was no problem, but under
  33. TOSWIN memory use skyrockets!   It seems to be a combination of tfork and
  34. toswin though as tfork'd processes grow huge when running and only the original
  35. memory is free'd and returned to the system, the rest is "owned" by pid 00.
  36.  
  37. Anyone working on unblocking Pfork() or Pvfork() ??
  38.  
  39.